home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19980424-19980901
/
000203_news@newsmaster….columbia.edu _Sun Jun 14 08:52:23 1998.msg
< prev
next >
Wrap
Internet Message Format
|
1998-08-31
|
5KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id IAA06032
for <kermit.misc@watsun.cc.columbia.edu>; Sun, 14 Jun 1998 08:52:21 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id IAA23007
for kermit.misc@watsun; Sun, 14 Jun 1998 08:52:21 -0400 (EDT)
Path: news.columbia.edu!panix!howland.erols.net!newshub.northeast.verio.net!newsfeeder.servtech.com!post.servtech.com!hal9000.buf.servtech.com!spamguard!rchandra
From: rchandra.spamguard@spamguard.letter.com
Newsgroups: comp.protocols.kermit.misc
Subject: Re: Scripts: INPUT timed out
Date: 14 Jun 1998 12:16:32 GMT
Organization: just by myself, connected through Verio New York
Lines: 80
Message-ID: <6m0ev0$lg1$1@post.servtech.com>
References: <357E3AF1.E299BFB3@eurospill.no> <6lm4sa$p24$1@apakabar.cc.columbia.edu> <3581331C.40C21962@eurospill.no>
Reply-To: rchandra.spamguard@spamguard.letter.com
NNTP-Posting-Host: hal9000.buf.servtech.com
Originator: 0x804b6e8@0x804b560
Xref: news.columbia.edu comp.protocols.kermit.misc:8878
In article <3581331C.40C21962@eurospill.no>,
Morten Knudsen <morten@eurospill.no> wrote:
>Frank da Cruz wrote:
>>
>> In article <357E3AF1.E299BFB3@eurospill.no>,
>> Morten Knudsen <morten@eurospill.no> wrote:
>> : I'm just starting to learn kermit script programming. My problem is
>> : that my input commands are all timing out. Also if I type interactivly
>> :
>> : output AT\13
>> : input 10 OK
>> :
>> : the input command fails. This .kermrc
>> :
>> : set line /dev/modem
>> : set speed 19200
>> : set modem usrobotics
>> : set dial prefix 0
>> : set dial method tone
>> : set input timeout-action quit
>> : output AT\13
>> : input 3 OK
>> : output AT\13
>> : input 3 OK
>> :
>> : fails on the second input line. Any hints?
>> :
>> Most likely, it is behaving as it should -- i.e. not seeing the second
>> "OK" within 3 seconds. I agree you *should* see it within 3 seconds, but
>> if the INPUT command times out, it means the expected text did not arrive
>> within the given interval.
>>
>> Another possibility is confusion with the communications port driver. I
>> notice you are using "/dev/modem", which probably means Linux? And /dev/modem
>> is what? /dev/cua0? /dev/ttyS0? The different drivers behave differently.
>> Unfortunately, this started happening (or was discovered) after C-Kermit 6.0
>> was released. In that case, you'll have better luck with C-Kermit 6.1:
>>
>I managed to solve the problem. I had to do:
>input 3 OK\13\10
>for some reason. But just for the AT commands. Apart from that
>all is normal. This is a USRobotics Courier on Digital Unix.
>/dev/modem is just a link. I haven't tried C-Kermit 6.1 yet.
>
>BTW, do anybody know how to get other speeds than 9600 and 19200
>(e.g. 14400, 28800, 33600)?
>
>> http://www.columbia.edu/kermit/ck61.html
>>
>> - Frank
>
>Morten.
My suggestion to you, and to Linux users as well, is, whereever
possible, do NOT use /dev/modem, use the device name to which it
refers. This keeps the lock files straight.
Even if you could set your port speed to 33600, would you really want
to? I think there's about a 75% chance you are confusing
modem-to-modem speed with serial port speed. Whereever practical, you
want to use a speed higher than the carrier rate so that the modem can
have data ahead of time to compress it before it is sent. The modem
will buffer the data for you, and signal your computer, usually
through the CTS line (and your computer signal the modem through the
RTS line), when it's ready for data and when it isn't. Of course,
your OS or your serial port or your serial cable may not support this
"hardware flow control", but if you've got it, it may be worth using.
Chances are, it can be done. Even if you're operating a V.32 (9600
bps) modem at 9600 bps, if you're using a protocol for error
correction, such as V.42, you need this anyway so that the modem can
request that you stop sending data while error correction retransmits
are in progress. Therefore, you might as well turn on compression and
modem speed buffering, and use a serial cable that supports RTS/CTS,
and take advantage of those modem features, if possible.
--
Oooooo-oooo-oooo-ooooo, Oooooo-oooo-oooo-ooooo, Ooooo-weem-oh-wum-ooo-ayyy
In the jungle, the silicon jungle, the process sleeps tonight.
Joe Philipps <rchandra-nospam@letter.com> http://www.servtech.com/~rchandra/
You know what you have to do to send email to me successfully :^)